Skip to main content

Use Cases

The DevAssure O2 Agent IDE extension supports a wide range of day-to-day testing workflows, from validating pull requests and hotfixes to executing CSV-driven scenarios and shared setup flows. These use cases show how teams can keep testing close to development while using O2 to focus validation on the most relevant code changes and application flows.

The extension is especially valuable when teams want fast local feedback, targeted execution, and a consistent path from editor-based validation to CLI-based pipeline automation. The examples below highlight practical ways to use O2 during feature delivery, debugging, release checks, and artifact review.

Pull request validation​

Use O2 in pull request workflows to validate only the scenarios most likely to be affected by changed code. This shortens feedback loops and improves release confidence without requiring full-suite execution on every change.

In this workflow, O2 evaluates the branch diff, maps impacted user flows, and runs the most relevant end-to-end tests for the proposed changes. This is a strong fit for feature branches, merge validation, and pre-review confidence checks.

devassure add-token <your-token>
devassure test --head feature/login --base main --archive=./reports

When to use​

  • Before opening a pull request for review.
  • Before merging feature branches into the main branch.
  • When teams want targeted regression checks instead of broad execution.

Commit-level hotfix verification​

When validating a hotfix or rollback candidate, commit-scoped testing helps isolate verification to a single changeset. This is especially useful for urgent fixes that need a fast but targeted signal before deployment.

This workflow reduces noise by focusing on one commit rather than a broader branch comparison. It is helpful when a defect has been traced to a known commit or when a single fix needs quick confidence before release promotion.

devassure test --commit abc1234567890 --workers 2

When to use​

  • Validating emergency fixes before production deployment.
  • Verifying a rollback candidate or patch commit.
  • Debugging regressions introduced by a specific revision.

Fast smoke regression​

Teams can filter scenarios by tags and priorities to run only business-critical checks before deployment. This pattern works well for release gates such as login, checkout, admin access, and dashboard visibility.

A smoke-focused workflow is useful when the goal is not complete coverage, but fast confirmation that the most critical journeys still behave correctly. It is also a good fit for pre-demo validation and rapid staging checks. [5]

devassure run-tests --tag=smoke --priority=P0

When to use​

  • Running a fast release gate before shipping.
  • Validating critical paths after a deployment to staging.
  • Checking platform health during active development cycles.

CSV-driven workflow​

Organizations that maintain scenarios in spreadsheets can run those tests directly without converting every case into YAML first. This is useful for operations teams, partner validation checklists, and legacy QA repositories maintained in tabular formats.

The IDE extension supports CSV-driven execution through the .devassure workspace, and the CLI can run the same inputs using --csv. This makes it easier to reuse structured test assets across technical and non-technical teams.

devassure run-tests --csv=.devassure/sample-tests.csv

When to use​

  • Reusing spreadsheet-based QA assets.
  • Supporting operational and partner testing workflows.
  • Importing test cases from legacy tabular repositories.

Shared setup and teardown for test suites​

Hooks are useful when every selected scenario requires the same authentication, seed data, or cleanup flow. Instead of repeating those steps in each test, teams can define shared behavior in before_all and after_all hooks to keep scenarios concise and easier to maintain.

This pattern improves consistency across the suite and reduces duplication in multi-step setup flows. It is particularly useful for authenticated sessions, test-data provisioning, and post-run cleanup of temporary entities created during execution.

after_all:
  summary: Cleanup test artifacts
  steps:
    - Log out from the application
    - Remove test users created during the run

When to use​

  • When all tests need a shared login or environment setup.
  • When test runs create temporary records that must be cleaned up.
  • When teams want to reduce repeated setup logic in scenario files.

CI/CD pipeline integration​

Token-based authentication and report export features make the DevAssure CLI well suited for headless automation in build systems. Exported JUnit XML files can be consumed by CI dashboards, while archived report zip files preserve rich run artifacts for debugging and auditability.

Although the IDE extension is designed primarily for interactive local workflows, this use case matters because many teams move naturally from editor-based validation to pipeline-based execution using the same DevAssure project structure and commands.

devassure add-token <your-token>
devassure run-tests --workers=4 --archive=./reports
devassure export-report --output-dir=./reports --last --format junit-xml

When to use​

  • Publishing machine-readable test results in CI systems.
  • Preserving reports from ephemeral build runners.
  • Standardizing local and pipeline execution around the same DevAssure project.

Example workflows​

The following workflows show how teams commonly use DevAssure across local development, change-based validation, and artifact management.

Basic local workflow​

This is the recommended starting path for teams adopting DevAssure in a local development environment. It covers authentication, project initialization, execution, and report review.

# 1. Login
devassure login

# 2. Initialize project
devassure init

# 3. Run tests
devassure run-tests

# 4. Open the last report
devassure open-report --last

Typical outcome​

This workflow gives teams a quick path from first-time setup to running executable tests and reviewing results without needing CI integration or advanced configuration on day one.

Code-change workflow​

This workflow aligns naturally with pull requests, branch previews, and merge validation jobs. It uses change-aware execution to focus on what actually changed instead of replaying a broad static suite.

# Test the diff of current branch vs default branch
devassure test

# Test explicit source and target branches
devassure test --head feature/login --base main

# Test a specific commit
devassure test --commit abc1234567890

Typical outcome​

This flow helps teams validate branch diffs and individual commits with a more targeted signal, making it useful for pre-merge review, hotfix validation, and fast regression checks on active code changes.

Report archival workflow​

These commands are useful for teams that want portable artifacts from ephemeral CI runners or need to reopen reports outside the original execution environment.

# Archive the last session report
devassure archive-report --output-dir=./reports --last

# Open a report from an archived zip
devassure open-report --archive=./reports/devassure-results-<session-id>.zip

Typical outcome​

Archived reports make it easier to share evidence across teammates, preserve debug artifacts, and review execution results after the original test session has ended.